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SYSTEM AND METHOD FOR ELECTRONIC 
DATA DELIVERY 

This application claims the benefit of U.S. Provisional 
application No. 60/139,171, filed on Jun. 15, 1999. 

The present invention relates generally to electronically 
delivering oil exploration and production data from an 
acquisition site to a delivery site. More particularly, the 
invention is a global electronic data delivery system and 
method of use for managing the delivery of oil exploration 
and production data. The present invention uses a workflow 
process that manages the flow of data from an acquisition 
site to a delivery site using a centralized data hub for 
real-time, point to multi-point data communications that 
includes a global communications network for secure and 
efficient data delivery. 

BACKGROUND 

In the oil and gas industry, operating companies that own 
and/or manage hydrocarbon wells evaluate the wells by 
wireline logging. In wireline well logging, one or more tools 
are connected to a power and data transmission cable or 
"wireline" and are lowered into the well borehole to obtain 
measurements of geophysical properties for the area sur- 
rounding the borehole. The wireline supports the tools as 
they are lowered into the borehole, supplies power to the 
tools and provides a communication medium to send signals 
to the tools and receive data from the tools. Commonly, tools 
are lowered to a depth of interest in the well and are then 
retrieved. As the tools are retrieved, they send data about the 
geological formations through which they pass through the 
wireline to data acquisition and processing equipment at the 
surface, usually contained inside a logging truck or a logging 
unit. 

The data acquisition and processing equipment, including 
software, compiles the data from the tools into a "log," a plot 
which presents the geophysical information concerning the 
geological formations encountered by the well, frequently 
by depth. Logs can also be used to evaluate current produc- 
tion from producing wells or to inspect the integrity of 
production equipment in a producing well. In any case, the 
data gathered during the logging operation is generally 
presented on the log by depth, but may also be presented by 
time, or any other index by which multiple physical entries 
are recorded. The data acquisition and processing software 
may send the log data to a viewing monitor, where the well 
logging professional (usually a "logging engineer") con- 
ducting the logging operation can view the log as it is being 
compiled. After the log is compiled, it can be transmitted to 
the operating company's headquarters for interpretation and 
review by management. 

The data acquired by logging is often crucial to the 
decision-making process on what will be done with the well 
being logged. Take, for example, a well that has just been 
drilled and logged. Depending on the results of the log, the 
well could be drilled deeper, plugged and abandoned as 
non-productive or cased and tested — or perhaps the decision 
will be that additional logs are required before the decision 
on the disposition of the well can be made. The results of the 
log may also help determine whether the well requires 
stimulation or special completion techniques, such as gas lift 
or sand control. In any case, these decisions are crucial and 
have to be made very quickly. Mistakes or even mere delay 
can be extremely expensive. 

The operating company which is drilling or producing the 
well frequently desires to have its own personnel viewing 
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the log data as the well is being logged. But the operating 
company may be located half a world away from the well 
itself. Drilling and production activities are often located in 
remote locations and it is difficult for the operating company 

5 to have its own personnel, such as a geologist or 
petrophycist, join the wireline company's logging engineer 
on site during the logging operation. Sometimes logistics or 
severe weather conditions prevent the operating company 
from sending anyone to the wellsite for the logging opera- 
tion. Furthermore, sending personnel to wellsites is expen- 
sive and exposes them to aD of the hazards of the drilling or 
production operation, as well as the hazards and inconve- 
nience of travel. As a consequence, tentative decisions often 
have to be made before the operating company can complete 
its review of the actual logging data, relying solely on the 
interpretations conducted at the wellsite. 

The oilfield operating company may have one or more 
service partners to provide technology, processes and ser- 
vices that bring increased operating efficiency at reduced 

20 costs. Among the partner's needs are the acquisition, 
processing, management and delivery of quality data. 

Each operator has unique views about and preferences for 
what is needed. Tnese needs vary widely and depend on the 
work ongoing, and result in a variety of the data to be 

23 handled. Some are currently focused on getting real-time 
data delivered directly to the desktops of all project mem- 
bers (employees, partners and service company experts), 
while others believe it is paramount to work towards a more 
comprehensive solution that includes data processing, man- 

3 q agement and product support. At the same time some 
operators prefer direct communications links, while others 
insist on only "pulling" data off of a secure, centralized, 
company-neutral server. There are as many permutations on 
the data delivery theme as imaginable based upon techno - 

35 logical capabilities, existing infrastructures within both the 
service company and operator domains, and operator pref- 
erences. In some cases, the lack of a standard process for 
setting up data delivery services causes operators and ser- 
vice companies to miss or even consciously pass up the 

4 0 opportunities presented by the technology. 

Further, the world is rapidly assimilating advances in 
electronic communications and web-based central data hubs 
demanding ever faster, more secure and reliable transfer of 
all data types around the globe. The exploration and pro- 

4 5 duction (E&P) industry is no exception to this trend. It 
desires time-efficient data acquisition with real-time and/or 
immediate post-job interaction with and integration of data 
to assist with project collaboration and decision-making. 
Acquisition sites are often temporary and in remote areas, 

50 lacking an established communications infrastructure. It is 
vital that a contractor's acquisition unit is able to leverage all 
possible communication methods it may encounter. For 
example, as many operators extend their Intranets to the 
acquisition site, contractor hardware must be capable of 

55 capitalizing on this, while providing the specific network 
security required by all parties involved. T ransmission pro - 
tocolsdesigned to get the data from the acquisition site must 
be^able to overcome what is often the least reliable link in 
the transmission chain. The protocol needs to be robust, 

60 efficient and maximized in recovery functionality. The data 
delivery system must accommodate several different time 
frames: real-time, post-job and long-term. Standard pro- 
cesses and facilities for creating links to oil acquisition sites 
and between companies must be established to facilitate use 

65 on more and more projects. 

World-class data delivery can only be achieved when the 
data transmitted is of the highest quality and adheres to 
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industry standards. Quality data is critical for making sound of the data during the transmission and delivery process on 

decisions and reducing risk. Such data, available as and private and public networks. 

when required by end users, is a common goal throughout all Each data transmission is a workflow order including the 

the data business segments: acquisition, processing, inter- destination and delivery type, for example, deliver by fax to 

pretation and management. Data content and composition 5 destination A and deliver data file to destination B. The order 

vary widely, from the numerous industry standards to locally can specify data conversion and customization based on 

devised data formats. To be truly seamless, a delivery system client profile. The central data hub manages the data delivery 

must handle all formats and data types encountered, con- and data conversions. The data delivery is point to muiti- 

verting between these formats if and when necessary. P oinl thereby allowing near real-time data delivery to mul- 

, . .j « - (J in tiple clients while the data is being acquired at an acquisition 

L^ewise, data can only be considered successfully deliv- 10 s jt e j± global communications network interface (Internet 

ered when it is incorporated smoothly into the client s wcb . bascd ) provides for the ordering of data delivery from 

domain and is available for immediate use and decision- virtually anywhere. Web based monitoring allows for the 

making. Thus, software applications must accompany hard- field engineer (or other clients) to check on the progress of 

ware developments to facilitate data reception, handling and data delivery from virtually anywhere. The centralized hub 

manipulation in the user's domain. All data transmitted must 35 archives the data delivery results and prevents duplicate 

be traceable and well managed, if it is to be supported and delivery and archiving. A transfer protocol with a unique 

used efficiently throughout its life. way of using pointers and sockets to interact directly at the 

Many data delivery systems have been established in the TCP/IP level allows for the bypassing of software middle- 
past and are in use today. Most have sub-optimal security, ware. The web-based interface allows for automatic soft- 
and do not offer seamless delivery of real-time data from the 20 ware upgrades form the central data hub, including the 
acquisition site to the delivery site with an integration of all addition of new software features. 

data streams, do not manage the process workflow of data The present invention comprises a data delivery system 

from the acquisition site to a data center to the delivery site for delivering oilfield data from at least one data acquisition 

of the data being transmitted, do not allow for point to site to a remote delivery site. The system comprises a central 

multi-point near real-time data delivery, do not offer seam- 25 data hub computer that processes a workflow order that 

less addition of new client/server functionality and do not controls delivery of oilfield data from at least one data 

allow for customized data delivery formats based on client acquisition site to a remote delivery site, a data acquisition 

specific profiles. site computer that transmits oilfield data over a first com- 
munications network to the central data hub computer in 

SUMMARY 30 near real-time in response to the workflow order and a data 

_ , . , r j j t* server that receives data from the central data hub over a 

The present invention solves the rtmwtonA needs It second communications networi5 . m data Knw commu . 

provides an apparatus, system and method thai substantially remote d ^ teRi for ^ 

e hmina to or reduce the disadvantages and problems associ- sjmultaneous ^ [ of ^ oilfield dala in near real time „ 

ated with the previously developed data delivery systems. 35 ^ mm k ^ computers in tesponse t0 , he 

The present invention provides for the seamless delivery workflow order 

of real-time data from the acquisition site (welisite) to the ^ ^ , workflow order at . 

delivery site (client sites) with the integration of aU da to . modu , e in , he cenlraJ data hub , ef ^ allows , 

streams It integrates the data movement from the welisite to ^ tQ ate ^ ^ wofkflow order to the central 

a centralized data hub, from the hub to data service centers, 40 ^ ^ ^ fot ^ ^ tem com . 

data management centers, product delivery centers, and to ^ a workflow order status monitoring moduk m the 

multiple client sites. The present invention manages the ^ data ^ ^ ^ monitors ^ ^ Qf a 

process workflow from theprodu<*r of the data to the data submitted ^Tk&ow order. 

centers and to the clients. The present invention centralizes .. ^, . , 4 . , H 
4 . . * . u*r. r j * j r a The system further comprises a data services center J 
the monitonng and trace abil ity of data delivery, provides 45 J . r , , . ,.7 
, ... i l v v M J i *u computer for post-acquisition oilfield data processing, thef 
built-in rec overa bility oi tailed op erations alo ng w ith dis - , * * ^ ... ■ <A 
, r, - i _ ; i i j i r . ' 4 . JI j „ r data services center computer being in communication witnl 
tnbuted managem ent or th e recovery by the e nd user or . t • * 1 
a dministrator. It uses data compression in its delivery appli- ^ cenUal ™>. THe system further compnses post- 
caTtonTIorTmproved utilization of communication band- acqu.sition odf.eld data Ptocsbiqb software applications 
t-u *• *• „ - t U1 „ . • fn within the data services center computer, the software appn- 1 
width. The present invention comprises an extensible archi- 50 . , . t , P , Y ... c * v 1 
tecture that allows for the seamless addition of new client/ catl0DS bcm S selected from the group consisting of borehole 
server side functionality without impacting the producer of s f mic applications, borehole imaging applications, petro- 
the data. It provides a workflow-based sysfem with capabil- P h V slcs applications, well test applications, production ent- 
ity to provide inter-dependency between the tasks of the neenn S Processing applications and interpretation function- 
workflow. It provides an integrated system that allows for 55 aUty a PP ucatlons - 

the export of data to data management archival systems. It The system further comprises an oilfield data archival 

provides a j fi al-tj rne store and forward capabilit y and cus- database in communication with the central data hub. 

tomization'of data based on client specific profiles. The In one embodiment, the data server comprises a File 

present invention reduces and simplifies the data delivered, Transfer Protocol (FTP) data server for transmitting oilfield 

both raw and processed data. It provides for point to 60 data 10 at l east 0De remote delivery site computer, 

multi-point data transfer and communication to a variety of In one embodiment, the data server comprises a global 

computer platforms, network connections and multiple sites communications network ("web") data server capable of 

using the central data hub that allows multiple clients to transmitting oilfield data in near real-time to the multiple 

access the same data in near real-time delivered in a variety remote delivery site computers via a global communications 

of client specified formats while at the same time archiving 65 network. 

and recording the data and graphics on various client speci- In one embodiment, the data server comprises a real-time 

fled media. The present invention provides for the security data server for transmitting oilfield data to multiple delivery 
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site computers in near real-time via a third communications 
network. The third communications network comprises a 
communications link and a communications protocol. The 
third communications network may be a global communi- 
cations network. The communications protocol for the net- 
works may be Transmission Control Protocol/Internet Pro- 
tocol (TCP/IP) or HyperText Transfer Protocol (HTTP) or a 
real- time communications transfer protocol. 

The first communications network may comprise a satel- 
lite communication network, a telephone communication 
network, a microwave transmission network, a radio com- 
munication network and a wireless telephone communica- 
tion network. 

The system further comprises a hardcopy delivery center 
that generates a hardcopy of the oilfield data as controlled by 
the workflow order from the central data hub, in communi- 
cation with the central data hub. The hardcopy is stored on 
media selected from the group consisting of a hardcopy 
report, a tape, a film and a CD-ROM. 

The central data hub comprises a user interface module 
that receives a user generated workflow order for oilfield 
data, a submission module that loads a description of the 
workflow order and breaks the workflow order into at least 
one task containing task parameters and task dependencies 
and transfers the task to a dispatch module for routing the 
task, at least one application module that executes the routed 
task, a status module that maintains the task dependencies 
and monitors task status, a data manager module that enters 
oilfield data in a database accessible by the central data hub 
and an archive manager module that handles the export of 
information for archival. The system further comprises a 
real-time data transfer module for transmitting real time data 
as specified in the workflow order from a data acquisition 
site to a data delivery site. The user-interface module inter- 
faces with a web browser for receiving the workflow order. 

The application module of the central data hub computer 
may comprise a data converter function that provides digital 
data conversion and data filtering of oilfield data as specified 
in the workflow order. The application module may com- 
prise a fax function. The application module may comprise 
publishing the oilfield data to a web server as specified in the 
workflow order, sending the oilfield data as specified in the 
workflow order to an external server using an FTP protocol, 
sending e-mail messages to a computer server as specified in 
the workflow order, converting data using a data conversion 
function as required in the workflow order or sending a 
hardcopy request to a product delivery center. 

The computer-implemented method further comprises 
transmitting oilfield data in near real-time via the data server 
to the multiple remote delivery site computers via a global 
communications network where the data server is a global 
communications network ("web") data server. The method 
further comprises transmitting oilfield data in near real-time 
from a real-time data server to the multiple delivery site 
computers via a third communications network. Processing 
the workflow order at the central data hub comprises receiv- 
ing a user generated workflow order for oilfield data at the 
central data hub, loading a description of the workflow order 
and breaking the workflow order into at least one task 
containing task parameters and task dependencies and trans- 
ferring the task to a dispatch module for routing the task, 
executing the routed task, maintaining the task dependencies 
and monitoring task status, entering oilfield data in a data- 
base accessible by the central data hub and handling the 
export of information for archival. The user generated 
workflow order is received by a user-interface module 



interfacing with a web browser The application module 
executes^ the routed task, converts digital oilfield data and 
filters t he data as specified in the workflow order, pub lis hes 
The oilfield data to a web server as specified in the workflow 

S order, sends the oilfield data as specified in the workflow to 
an external server using an FTP protocol, sends e-mail^ 
messages to a computer server as specified in the workflow 
order, sends a hardcopy request to a product delivery center 
and se nds oil field data in near real-time data from the data 

1Q acquisition site to the multiple remote delivery sites. Oilfield 
data is sent in near real-time from the data acquisition site to 
the multiple remote delivery sites as specified in the work- 
flow order. 

In one embodiment, the method in a computer data 
5 delivery system for delivering oilfield data from at least one 
data acquisition site to multiple delivery sites comprises 
receiving a workflow order for oilfield data at a central data 
hub computer. The received workflow order at the central 
data hub computer is then executed. If the task parameters 

2Q are valid, the task is submitted for dispatch which comprises 
loading the description of the workflow order, breaking the 
workflow order into at least one task containing task param- 
eters and task dependencies, if task dependencies are satis- 
fied dispatching the task for execution, executing the task 

^ and monitoring task status. 

Submitting the task comprises receiving a workflow order 
request at a submit server within the central data hub, 
validating the workflow order and placing the workflow 
order on a dispatch queue. If the workflow order is a task 

3 q abort request, processing comprises receiving a workflow 
order request at a submit server within the central data hub, 
validating the workflow order and placing the workflow 
order on an abort queue. Dispatching and executing the task 
comprises processing tasks in a dispatch queue by routing 

35 the task to an appropriate application server for execution. 
The application server may comprise a digital data con- 
version and filter application, a web dropbox server for 
sending data to a web server, a fax application server for 
sending the oilfield data to a fax machine, a file transfer 

40 protocol (FTP) server for sending files to a server external to 
the central data hub using FTP protocol, a PDS rasterize 
application server for converting data from PDS graphical 
formats to other graphical formats and a hardcopy applica- 
tion server for sending a hardcopy requests to a product 

45 delivery center. The application server may also comprise a 
real-time transfer application server that sends data to and 
receives data from a real-time server. A second real-time 
transfer application server is located in the data acquisition 
system for sending oilfield data in real-time to the central 

50 data hub. A third real-time transfer application server is 
located in the remote delivery site computer for receiving 
oilfield data in real-time from the central data hub. 

The method further comprises a data manager within the 
central data hub that locates data and enters new data into a 

55 database in communication with the central data hub and an 
archive manager for managing file data uploaded to the 
central data hub and file data generated at the central data 
hub via file conversion applications. The monitoring of the 
task status comprises processing status queue task 

60 dependencies, task messages and task statistics, maintaining 
task and order state statistics, identifying tasks waiting for 
events and placing tasks in a dispatch queue when task 
dependencies are complete. Task dependencies include 
executing the task after other tasks have completed or after 

65 a period of time has elapsed. 

In one embodiment, the computer-implemented method 
for near real-time data delivery of oilfield data from at least 
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one data acquisition site to multiple remote delivery sites, FIG. 12 is a flowchart of the dispatch server processing, 

comprises processing a workflow order at a central data hub piG. 13 is a flowchart of the status sever processing, 

computer that controls delivery of oilfield data from the data mQ u k a di f ^ aiositioDS main . 

acquisition site to the remote delivery site transmitting ^ b ^ smu ^ xtvCL 

oilfield data over a first communications network from a s \ m . 

data acquisition site computer to the central data hub com- ™; 15 » a of ^ ordcr statc transibons main- 

puter in near real-time in response to the workflow order and tamed bv ^ status server 

sending oilfield data from the central data hub to a remote FIG. 16 is an exemplary display of a user interface for 

delivery site using a data server that is part of the central data ordering and submitting a workflow order, 

hub, the data server communicating with multiple remote 10 FIG. 17 is an exemplary display of a user interface for 

delivery site computers for the simultaneous display of the specifying and displaying tasks dependencies for tasks in the 

oilfield data in near real time at multiple delivery site workflow order. 

computers in response to the workflow order. FIG. 18 is an exemplary display of a user interface for 

In one embodiment, the computer implemented method specifying data conversion for the workflow order, 

for near real-time data delivery of oilfield data from at least 15 FIG. 19 is an exemplary display of a user interface for 

one data acquisition site to multiple remote delivery sites, specifying graphics conversion for the workflow order, 

comprises electronically transferring oilfield data obtained pig. 20 is an architectural diagram of the electronic data 

at a data acquisition site from a computer at the data n ub 
acquisition site, based on a user-specified workflow order 

program, to a central data hub computer over a communi- 20 DETAILED DESCRIPTION OF THE DRAWINGS 

cations network using a near real-time transmission i . . , t e iU , . 

, . . ,* 't£i ij j t * *t_ l i j ± l i_ FIG. 1 is a system architecture diagram of the data 

protocol, receiving the oilfield data at the central data hub , A ' ™_ , . , ° . ... 

r ' - .*? . « j * c j i * * *u i*- 1 delivery system 10. The data delivery system with its 

computer, formatting the data for delivery to the multiple c J ' * t_ j j j *u j * 

\ , v j ,i j i • J . 4 . , framework components has been designed around the data 

remote delivery sites based on the delivery site requirements A , , , * - . iL , « . 

» .« .« j , « .l j , , „ to be handled, the data workflow, the tune domains to be 

and the user-specified workflow program, routing the data to 25 , A \ , . . 4 ' , _ , 

,j j,. * uj accommodated, and the vanety or computer platforms and 

a hardcopy delivery site for hardcopy creation based upon . ' ./ „ -A « u u 

. 1%, 3 « « . \ a j network connections available. Specifically, it has been 

the workflow as requested by the workflow and routing the , . , , A . . 

* j . .* 1t . 1 . j 1 • •„ i_ j *l designed around three mam sites or functions: the acquisi- 

data to the multiple remote delivery sites based on the . * , „ x „ . , % / 4 , „. \ i . 

j fa j ... . tion site (wellsite) 11, the delivery site (operators office) 12, 

user-specified workflow over a second communications net- , v •/ L *L j * • * 11 

. r . t . . , in and the auxiliary sites such as the data services center 13, 

work using a near real-tame transmission protocol upon 30 ^ ^ d center _ 

request by at least one of the multiple delivery sites. The ° . , , , , 

method comprises a built-in data recovery module in the t ™f? ~«™«f«. fl*"** a .^ e <= e f al data 

central data hub for recovering data if the transmission of the hub 16 ^ough not expli«Uy shown in FIG. 1, there may 

oflfleld dau from the data acquisition system to the multiple be multl P le delivery sites, auxiliary sites and acquisition 

remote delivery sites fails and a data compression module 35 connected to the central data hub 16. The hub 16 

for compressing data transmitted over the first, second and rece j ve f f ata and forwards it to the required ocations, either 

third communications networks. to the slte U > to an « = 13 - 15 , « •» 

The computer-implemented methods are embodied in ^ition site 11. The central data hub 16 may be located 

c . r * i.t „ , either within a secure Intranet or within an associated secure 

software programs that may be stored on a computer- t _. . , , A 41 _ t . ..l 

readable medium. « enclave. Digital delivery to the delivery site (in this case the 

operator's desktop) 12 is achieved through the use of data 

BRIEF DESCRIPTION OF THE DRAWINGS forwarding protocol (File Transfer Protocol or others), 

These and other features, aspects and advantages of the e-mail attachment, fax transmission or World Wide Web 

present invention will become better understood with regard (WWW) delivery through a web data server 18. The system 

to the following description, appended claims and accom- 45 can also accommodate point-to-point communication 17 

panying drawings where: directly between the acquisition site 11 and the delivery site 

FIG. 1 is a system architecture diagram of the data 

delivery system. Associated with this central data hub may be at least one 

FIG. 2 shows the data management system architecture. product delivery center 15 comprised of specialized hard- 

FIG. 3 is a system architecture diagram of an alternate 50 ware and software systems designed specifically to generate 

embodiment of the data delivery system. hardcopy output in the form of products such as prints, tapes, 

FIG. 4 is a system architecture diagram of an alternate ? lms ™ d ^ The product delivery centers 15 may be 

embodiment of the data delivery system. ° cated loc ^ * OT f m tors °f ccs at thc Slt * 

„ . , ft / /■ . 12 or may be located virtually anywhere, removing the need 

FIG. 5 is a system architecture diagram of an alternate c , J . . , . A \ tL ; . ... ° KT , , 

* * * 4 . 4 . 4 to 55 for products to be generated at the acquisition site. Network 

embodiment of the data delivery system. A r . . 4 4 . , 1 * ^ < . .1 

, transmission to the local product delivery centers 15 greatly 

FIG 6 is a system architecture diagram of an alternate reduces duct ^ ^ from remote ^ i{im 

embodiment of the data delivery system. siteg ^ cefltral data ^ product deliyery 15 

FIG. 7 is a system architecture diagram of an alternate asj ^ m web data server 0 f choice 18 are typically, but are not 

embodiment of the data delivery system. 6Q required to be> co -located within a single data service center. 

FIG. 8 is a diagram of an exemplary secure enclave Tn e data delivery framework is flexible and can be config- 

connectivity center. ure( l m a nU mber of ways. There are many permutations on 

FIG. 9 is a diagram of the central data hub architecture the data delivery theme depending upon the preferences of 

and interfaces. an operator at project time, as well as the communications 

FIG. 10 is a table of central data hub external interfaces. 55 configuration of a given acquisition site. 

FIG. 11 is a flowchart of the submit server processing Desktop hardware and software tools located on the 

within the central data hub. operator desktop at the delivery site 12 or on desktops at the 
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data services center 13 complete the data delivery frame- Programmability — A Component Object Model (COM) 

work system components. The tools facilitate the reception, interface allows the Transfer express modules to be plugged 

handling and manipulation of data, received either physi- into any Microsoft Windows application. This simplifies file 

cally or electronically, and assist the operators with their transfer, and provides customized transfer status updates, 

next step decision process, be that data integration, 5 options settings, and complete error-handling integration 

interpretation, processing or archiving. into that application. 

Data Scrambling — All data moved over the link is 

Data Acquisition Site scrambled, and is not easily discernible from its original 

Data delivery from the acquisition site 11, including both values, 

measurement data and job status information, may be trans- 10 Multiple Platforms — The transfer express system is 

mitted over satellite, land line, microwave, ISDN, cell multi-platform and provides seamless file delivery of both 

phone, direct Ethernet connection or by any method that binary and text across UNIX, VAX and Win32 platforms, 

supports the TCP/IP protocol. Generally, either the operator Firewall Limitation— The transfer express system limits 

or the service company provides communications from the firewall changes by requiring that the two systems have only 

wellsite. In either case, the service company's data acqui- 15 one operational TCP/IP link 
sition system must include hardware and software to allow 

it to communicate over any of these various links using Data Delivery Format 

standard protocols. Since data files can be written over hours _ , ... . 

(wireline) or days (for, example, in logging-while-drilling . Data generated at the acquisition sites 11 and interpreta- 

(LWD) operations), the ability to transmit files as they are 20 " on s y s * ms ( such , a r s ,he data L semces ce f nter 13 ) ,f» 

being created is an essential facet, crucial to timely decision- delivered m ^"i folmSr ^*f iCS : ™ .* cd ? ed 

makins Picture Description System (PDS), and digital data in either 

A 8 ' . . , , , , , Log ASCII Standard (LAS) or Digital Log Interchange 

A router-based mobUe connection solution, designed to SUndard (DUS) format For , oggmg . whi i e ^ ril]ing (lwd) 

facilitate connection of the acquisition unit to the most and other driuin daU the WeUsjt6 Infonnation Transfer 

common communications methods encountered ('standard SUndard (wrr g ) ig ^ ei , her online of fa batch 

modem dial-up, ISDN or Ethernet) may be used. Intended mode for real ., ime Qr near real ., ime (nnsfct mjs daU 

for mobile systems that must reconfigure their network format is based 1(Josel 0Q ^ ^ Information standard 

connection on a regular basis, it consists of a router, power /* to\ 

supplies and connectors, along with a software interface _ _ ' . , . . . . . , ■ . . . 

preconfigured and ready to enable any Internet Protocol (IP) 30 Coupling advances in both downhole acquisition techno - 

based network application. It is designed for users who are <>& and data telemetry technology with the industry s 

not networking specialists and is straightforward to set up unabated , <! emand J™ ^tton infonnation has 

and run. The software 'manager' provides network and drastically increased the volume and complexity of the data 

connectivity information and assists with trouble-shooting, « being acquired. Complex data are delivered primarily in 

automatically indicating where and when a link has dropped 35 d/f^ 1 f ° mat ln ^dition to the graphical data formerly 

t delivered on paper. Categonzation and documentation of the 

data delivered has become increasingly necessary. As part of 

Transmission Protocol a client data delivery initiative to categorize data delivered, 

default classifications include: 

Tie data delivery system needs to transfer data from the 40 ^ . ~ 4 ^ t . .... n , . 

- t t J J .... n . u 1 j Basic Data — Contains the data, usually presented 

often-remote temporary acquisition site 11 to a site hooked „ , . . . , ' c c • , ¥4 

. t_ 1 * . . • • e « rp» « . optically, used as is by a broad spectrum of professionals. It 

to an established communication infrastructure. The data . r v . . i . u . , r - t . , r , . 

« u.j«r*. 15 hmited in size and is suitable for timely exchange and 

delivery system includes a robust and efficient communica- ' V 1 *t t' 

tions transmissions protocol, called transfer express that " ^ 1 

maximizes successful transmission from these sites and 45 Customer Data— Contains the basic data and the essential 

provides file transfer capabilities across Transmission Con- minimum data that supplement and supports it. It is suitable 

trol Protocol/Internet Protocol (TCP/IP) networks. The pro- for data stora S c and advanced exploitation by specialists, 

tocol queries remote file systems and sends and receives file Producer Data — Contains, in addition to basic and cus- 

data. It uses a client/server model similar to that used by File t°mer data, data meaningful to the producer of the data. 

Transfer Protocol (KIT), but transfer express provides more 50 To allow data delivered to customers to be accurate, 

efficient recovery and communications operations. If a com- comprehensive, consistent, accessible and shareable, data 

munications link is tost during sending of a data file, with products have been defined that adhere to agreed-upon 

FTP or email the file transfer is aborted. This requires the policies, requirements and standards. A unique data 

entire file to be sent again once the link is resumed. The exchange standard, Recommended Practice/Digital Log 

transfer express system, on the other hand, recovers grace- 55 Interchange Standard (RP66/DLIS) has been implemented, 

fully. When the communications link becomes available, the Developed by a group of oilfield industry leaders, including 

transmission will continue from where it stopped. FTP and Schlumberger, this data exchange format became an Ameri- 

email are also very inefficient with file size. M P provides no can Petroleum Institute (API) Recommended Practice 

compression and email often expands the size of attached (RP66) in 1991. The Petrotechnical Open Software Corpo- 

binary files. The transfer express system provides compres- 60 ration (POSC) adopted it in 1992, triggering its development 

sion to a maximum of six times, minimizing transmission as a syntactic standard for seismic, drilling and well logging, 

time and maximizing bandwidth usage. In addition, the The Digital Log Interchange Standard (DLIS) proposes a 

transfer express system provides the following functionality: data schema or model that permits the storage, management 

Real-time Transfers — the transfer express system moves and exchange of quality data, as previously defined in the 

the data to the receiving computer as it is being generated. 65 classifications listed above. Through a description of 

This allows data transfer from an open file, facilitating the equipment, tool, process and data, the format ensures the 

real-time transfer of data during acquisition. traceability required by the E&P industry. It supports a way 
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to classify data for purpose and consequently provides ease package, originally designed for point-to-point (standalone), 
of data access. The standard also conveys the software two way transmission. The interactive software package can 
producer's semantics for tool, equipment, process, channel use the transfer express transmission protocol for commu- 
and parameters via official descriptions stored in the specific nications allowing it to be used point to point or in con- 
data record. S junction with the central data hub for multi-point transmis- 

riT tc «u-^tc _ • Mt lrp . sion. Real-time point to multi-point communication to 

DLIS objects (such as tool, equipment, process, channel, , •* i*» • l • j -l j • t-f^ ia 

, \ s -j * c j u j- I- * ii j delivery sites 12 using a web server is described in FIG. 20. 

and parameter) are identified by dictionary-controlled ™ ; . L i- L j , • • . 

n . . . , r r-xT io These established real-time services comprise mst one 

names. Registering proper names and properties for DUS f " r .u j 7j r cT in J . 

A . • . . i . j i , facet of the data dehvery framework. Real-tune cornmuni- 

objects is a prerequisite to any product development and ^ ialis * t0 ide time] rtise on 

commercialization For example Schlumbeipr rnaintains a « k ^ w £ rldwide fro J a ]oca > Qn * muUi lc 

public version of its Oilfield Services Data Dictionary locations. Remote witnessing not only provides optimal use 

(OSDD) on the web. It also endeavors to document the of key staff> but ^ reduces teavel ^ and persoim ei 

products, especially the digital data (rationale, genesis and exposure to hazardous environments. Further to this, it 

qualification). facilitates capture and dissemination of best practices, with 

The data delivery format for log graphics is called PDS, 15 the same staff collaborating on many wells in a specific field 

which has been designed specifically for log graphics. It is or region. Today's model for decision-making is thus 

a sophisticated, intermediate-level, device independent, becoming expert-centered versus asset-centered, including 

standard graphics protocol used to describe, store and trans- web-based real time remote witnessing, 

port log graphics as efficiently as possible. PDS can be Central Data Hub 

stored on tape or disk and can be viewed on screen displays. 20 w ^ ^ ^ transmiUed with an accomp anying work 

The end user does not have the capability to change the 0fder from ^ acquisition siu to a Dcarby wnM data hub 

details of the PDS file; however, the ability to add and u which u specifically designed to receive the data and 

remove annotations is possible. carry out thc order central data hub 16 hardware and 

WITS was designed as a joint industry effort sponsored by ^ associated software provide fully traceable processing capa- 

the International Association of Drilling Contractors (IADC) bility for transferring large data and graphics files of any 

and is the generally accepted protocol for sharing data type from one location to another with high reliability and 

among various contractors on a rig. In WITS, standard efficient use of bandwidth via compression. Central data 

records are defined to provide data on rig conditions, direc- hubs may be deployed around the globe in close proximity 

tional surveys, cementing, basic formation evaluation and 30 to data acquisition sites, achieving a global communications 

other common rig activities. In addition, there is a provision network for data delivery. 

for custom records that allows any kind of proprietary data Central data hubs 16 automate rapid data and product 

to be exchanged as long as the data in the records has been delivery, using multiple electronic delivery methods (fax, 

agreed on between the sender and the receiver. WITS is an ™J eraail > ^ ° r product delivery centers 15 for 

appropriate format for drilling data transmission due to its 35 h f™W generation. An order-based processing system 

u-r* ♦ j , , . , e « 35 allows logical queuing, execution and tracking of tasks. The 

ability to transfer depth-stamped data efficiently as soon as ^ ^ ^ ^ aUows ^ em * m ^ date 

*h^i aC ?!i U *^ This key feature eliminates the need to wait on * ^ 

the last data to be acquired m a bottom hole assembly (BHA) _ 4 „ . a e n „*«f u„u, i™* 

. r , j . ti _ z 1 . . Ti . ... 4 j Detailed records of all central data hubs are kept, resulting 

before starting the transmission. It is possible to reproduce « ... , . t „ , , u- t ♦ 

. b „ « , . . * » £ j ma comprehensive audit trail. Data and graphics tormat 

the acquisition system database m the operator s office and , n . r . . , , . . , J ^ . . 

H _ . J . v 4 - * 1 r *u 40 conversion is also supported, which can be specified and 

run any of the acquisition applications remotely lor the A , , . » u * n j * « 

' f . . j . 4 tL j » u • 1 standardized on a per-operator basis. Resource editors allow 

purpose of viewing and interpreting the data being acquired. A , * 4 j , . , , 

K» r . & 1 * j « • *u 1 * users to create, edit and delete resources such as customer, 

The remote user can select and customize the logs to f ' . - , .. . ... T * 

.... JilLi -Tj well, fax machine, transfer destinations and the like. It 

generate any file format with any data that was acquired and „ ' , L . j , , , + £ , . . . 4 . . ... 

f - ti .V iU • ■* 11 allows the central data hub 16 administrators to create, edit 

transmitted from the acquisition site 11. AK . , . . . . , . . . . . . 

^ 45 and delete resources such as the dropbox, central data hub, 

Real-Time Interaction data center and transfer resources. The change context utility 

. allows for the modification of the company/well focus in the 

The data delivery system 10 provides for interactive, scssion to ^ data hub u A user cdit0f allows 

real-time, collaborative viewing of acquisition site data in admimstrators t0 create? edit ^ de i et e user records. A 

the operator's office 12 is a key and growing need in today's 50 ck utiUty allows administra tors to archive old order 

E&P industry. This is especially true relative to interpreting fecords and femove file da(a ffom the system without the 

critical drilling and logging data, both of which are used for loss of aQ audit tra0 A change applications utility 

*next step' formation evaluaUon and well construction administrators to customize which applications are available 

decision-making. m ^ ^ mter f ace Th e change fax routing allows admin- 

Specifically, drilling mechanics, resistivity and sonic data 55 istrators to determine the origin of the fax deliveries, either 

are delivered in real-time through WITS to facilitate pore f rom me central hub or a remote fax unit of the central data 

pressure analysis for selecting casing points and minimizing hub 16. The server manager allows administrators to control 

fluid loss while drilling. Sonic (Delta-T) data while drilling me back end servers of the central data hub 16. 

are delivered to data service centers for integration and The ccntral hub hardware 16 typically consists of a 

correlation with seismic data in order to "put the bit on the m h i g h-end PC server with dual processors, dual power 

seismic map" and update the well plan in real time. LWD supplies> a large ^ Redundant Array of Independent 

data are delivered for real-time integration into a reservoir Disks (RAID), a floppy disk, DAT drive, CD-ROM, fax 

model for the purpose of geosteering. board> and netwo± adapter 

Getting the logging information to the right people at the 

right time and place — wherever they may be relative to the 65 
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wellsite — may be achieved through point to point commu- The central data hub 16 also provides the means to take 
nications 17 using an interactive remote witness software advantage of all auxiliary services. Auxiliary services 
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include data service centers 13 for processing and advanced Web Data Server 
interpretation of data obtained from the acquisition site 11. 

Auxiliary services also include data management centers 14. Turning back to FIG. 1, in order to provide timely data to 

As the complexity of evaluation tools and their acquired data a krge, global audience, the Internet and more specifically 

increases, and the value of integrating these data is realized, 5 me World Wide Web (WWW) is being utilized. A platform 

post-acquisition interpretation and processing becomes an independent software package facilitates the delivery of 

integral part of the data delivery framework. Data service digital and graphical wireline logs that have been converted 

centers 13 exist to process newly acquired data to various and transmitted from the central data hub 16 to a web data 

levels and/or perform reservoir and formation evaluation server 18 to operators at a delivery site 12 via the WWW. 

field studies on data of any vintage or from any source. FIG> 3 is a tem archite ct U r e diagram of an alternate 

Staffing of a ^typical data service center includes am* of log embodiment of the data delivery system 30. The data 

analysts and interpretation experts qualified in the major ^Wety system 30 features an acquisition system 31 at a 

geoscience disciplines^ well acquisitioQ site> point tQ im communication 37 

Data ™^ center ™ hardware systems typically center between the isition tem 31 and tor deskto at 

on a Umx OS Microsystems or Silicon Graphics work- me deU ^ 32 ^ * * 

station network. The range of software applications aval- e ^ 7 t i , . . . c \- , 4 

able is extensive, encompassing borehole seismic, geology, futures a central data hub 36 for accepting weusite data 

borehole imaging, petropbysicS, well test, and production with an accompanying work order from the 

engineering processing and interpretation functionalities. acquisition site 31 to a nearby central data hub 36, which is 

The data management center 14 is an integral part of the ^cifically designed to receive the data and carry out the 

data delivery framework and integrates data from the dif- ™ order. Data service centers 33, data management centers 34 

ferent domains (seismic, drilling, production, reservoir). The for archiving data and product delivery centers 35 as dis- 

data may be either recently acquired or pulled from archive casscd abovc for FIG - 1 are also provided. The product 

in order to exploit the knowledge from data previously delivery centers 35 provide for hardcopy (prints) 40, tapes 

acquired, and benefit from the experience provided as part of 41 and CD-ROMs 42 and the like of the well acquisition site 

the data management center 14. The data management 25 data - When transmitting data from a well acquisition site 31 

centers 14 allow for the combination and correlation of to the central data hub 36, the engineer can select as the 

trusted data among multiple wells and disciplines. delivery vehicle an FTP data server 38 which communicates 

FIG. 2 shows the data management system architecture with the operator desktops 32 (delivery site) using File 
20. The data management center (FIGS. 1, 14) contains a Transfer Protocol (FTP) communications 43. Alternatively, 
master data catalog 21, a wells database 22, geology data- 30 the engineer can select as the delivery vehicle a web server 
base 23, comprehesive well log database 24, a seismic 39. One type of communication that can be used with the 
database 25 for data from a seismic data management web server 39 is a secure operator web 'drop box' that 
system (for archiving, viewing and restoring bulk seismic accepts data from the central data hub 36. Associated with 
data), a physical asset database 26 along with other data- this drop box 39 is a notification list for the end user, which 
bases 27. The data management center contains a record 35 captures data processing parameters, the data format 
inventory management system that allows oil companies to delivered, and any customization filters specified by the 
store, organize and track a wide variety of physical E&P data operator. Prior to delivery to the drop box 39, emails are sent 
assets. Users may utilize a Web access application to to the end users at the delivery site 32 advising of an 
browse, select and retrieve data in all supported formats to impending delivery. The central data hub 36 waits for the 
a local machine, for example, a data processing workstation. 40 completed delivery of the logging data from the acquisition 
The data management system architecture 20 has been site 31, and then automatically delivers it to the specified 
designed around the data management and data access web data server drop box 39. Subsequently, a final automatic 
functions: loading, validation, editing and integration; find, email notifies the user that the data is available for down- 
access and transfer, respectively. loading. An alphanumeric pager may be used in place of 

How the data management process integrally ties to the 45 email as a means to notify the end user of data posted in the 

data delivery framework can be shown using an example drop box. 

from the database management system developed for log FIG. 4 is a system architecture diagram of an alternate 

data (wireline or LWD) data. The data delivery system embodiment of the data delivery system 50. It features an 

(FIGS. 1, 10) periodically copies log data files (DLIS and enhanced web-based delivery system built to handle E&P 

PDS) from the central data hub 16 to the data management 50 data. The data delivery system 50 features an acquisition 

center 14 with its archive system using a communications system 51 at a well acquisition site, point to point commu- 

protocol, such as the transfer express protocol, together with nication 57 between the acquisition system 51 and operator 

a descriptive text file. The log database receiver in the data desktops at the delivery site 52. The data delivery system 50 

management center 14 processes then parses the description also features a central data hub 56 for accepting wellsite data 

file to retrieve log data files to be loaded and archived. 55 transmitted with an accompanying work order from the 

During the autoloading and archiving process, the database acquisition site 51 to a nearby central data hub 56, which is 

system continually updates a HyperText Mark-up Language specifically designed to receive the data and carry out the 

(HTML) report, which the operator at the delivery site 12 order. Data service centers 53, data management centers 54 

consults via the central data hub 16. for archiving data and product delivery centers 55 as dis- 

For graphical data management, a PDS scanner is imple- 60 cussed above for FIG. 1 are also provided. The product 

men ted within the database management system (FIGS. 2, delivery centers 55 provide for hardcopy (prints) 60, tapes 

20), in order to extract the field and well names from a PDS 61 and CD-ROMs 62 of the well acquisition site data. Data 

tape. This improves the accuracy of the information put in is transmitted from a well acquisition site 51 to the central 

the log database when a PDS is loaded. After the PDS and data hub 56 and then sent to an electronic hub (eHub) web 

the DLIS tapes have been autoloaded, they may be archived 65 data server 58. The eHub 58 is the single point of entry for 

according to the archiving policy defined in the log database web-based data delivery from the operator's desktop at a 

(FIGS. 2, 24), delivery site 52 and subsumes the functions of the FTP 
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server and web data server (FIGS. 3, 38 and 39). The eHub 
58 provides a security framework, administration and deliv- 
ery protocol (HTTP). The eHub 58 provides for file delivery 
53 to the operation desktop 52. File delivery 53 has been 
modified to allow for real-time data delivery. The eHub 58 5 
also hosts a Web Data Delivery (WebDD) software appli- 
cation that forwards real-time oil drilling data 54 to the 
operator desktop at the delivery site 52. The Web Data 
Delivery software application allows customized formatting 
and views of the data in real-time. A set of base services is 10 
provided at the eHub 58 with the extension of custom 
applications available. The eHub 58 also allows for multi- 
point communications 59 between the eHub 58 and multiple 
operator desktops at the delivery site 52. The multi-point 
communications allow the engineer to send well data from 15 
the acquisition site 51 to the eHub 58 where multiple clients 
can then pull the data onto their customer desktops 52 
simultaneously. Alternatively, the engineer can send the data 
to the customer desktop using point to point communica- 
tions 57 but to have the data viewed by multiple clients, 20 
multiple sessions and point to point communication links 57 
are necessary. 

Referring now to FIGS. 3 and 4, both the eHub web data 
server 58 and the web data server 39 are an online repository 
for all data accumulated during well construction. It allows 25 
operators immediate access to their data and reports, and the 
status of ongoing services, regardless of where in the world 
these services are taking place. Morning reports, bit run 
summaries, logs and real-time data files will be published on 
the server for web access by authorized operator personnel. 30 
The files are organized into a hierarchy that allows clients to 
browse and download data as required. Operators will be 
able to access all information pertaining to a well (or nearby 
wells) required to make critical decisions from any location 
having web access. Through real-time access, decisions may 35 
be made that affect the actual placement of the well being 
drilled. 

Several eHub 58 or web 39 data servers may be 
established, allocated to specific operators, and positioned 
close to the operator's domain. This allows data to be 40 
'pulled' from the web data server by authorized operator 
personnel, rather than being 'pushed* into the operator's site. 
The end user at the delivery sites 32 and 52 thus has control 
of when and where the data are delivered. 

45 

All data and requests are transmitted through the eHub 58 
and web data server 38 using a tiered security system using 
secure Internet protocols (HTTPS). The user only has to 'go' 
to one location to obtain data or monitor job status. Once the 
user has 'bookmarked' the location of the nearest eHub web 
data server 58, it becomes his or her source for current or 
archived data. 

The eHub 58 and web 39 data servers incorporate the 
following features: 

Operator Log-in Authentication — Users are registered in 55 
an industry-standard Lightweight Directory Access Protocol 
(LDAP) database that identifies their company, their 
organization, and the data they are allowed to access. Once 
authenticated, the user has access to all data and services 
permitted under his given profile. User log-in will be con- 60 
trolled using digital certificates (or secure passwords) that 
verify user identity. 

Standard Browsers — The interface to the web data server 
is via standard browsers (Netscape or Internet Explorer). 
'Plug-ins' or Java applets can be used to provide enhanced 65 
finctionality, removing the need for special software for 
basic download capability. 



50 



Customization — Within the integrated framework, it is 
possible for custom displays and applications to be run (such 
as specific applications and displays for well logs or seismic 
coverage graphs for seismic work, among others). 

Referring now to FIGS. 1, 2 and 3, the product delivery 
center (PDC) 15, 35, 55 is a dedicated, offsite facility staffed 
with specialists that comprises the hardware and software 
specifically needed to produce hardcopy end products such 
as prints and films, tapes and CDs. Workflow is automated 
through the system, including the PDC. Although the inher- 
ent quality and finalization of the product remains the sole 
responsibility of the acquisition engineer, the offsite product 
generation allows the engineer to leave the acquisition site 
earlier. The PDC is designed to capitalize on the efiicient 
flow of transmitted data from the acquisition site via the 
central data hub 16, 36, 56, but its benefits can also be 
leveraged even when configured stand-alone through the 
physical delivery of data tapes. 

In addition to a standardized, engineered solution for 
product delivery, the PDC also offers a queuing capability. 
The authorized acquisition engineer or manager can log into 
the central data hub at any time and monitor the status of the 
submitted order. As with the central data hub, order trace- 
ability is available. 

Product delivery center hardware consists of a PC server 
with CD-ROM, internal DAT drive, network adapter, a 
scalable array of printer front -end PCs and high-speed color 
log printers. Label printing facilities exist for both the 
CD-ROM and DAT media. 

CD-ROM production provides operators with an alterna- 
tive to tape delivery, with an improved shelf life and higher 
endurance to temperature, humidity and magnetic fields. 
CDs provide an easy-to-use solution with cross-platform 
compatibility. Written following the widely accepted ISO- 
9660 standard, CDs can be read back on nearly any com- 
puter platform. In addition, PDC-written CDs provide a 
consistent product to operators. 

Referring now to FIGS. 1, 2 and 3, the data delivery 
framework has been designed to allow operators 12, 32, 52 
to receive data both at home or in the office. An end user is 
only required to have a basic PC with either a network 
connection or a CD or tape drive. Several software utilities 
have been compiled into a 'tool box' utility to facilitate the 
reception, handling and manipulation of electronic log data 
received either real-time or post-job, facilitating the 
decision-making process. 

This basic utility package offers graphic data viewing and 
annotation for PDS as well as functionality to convert PDS 
to the more general graphic formats encountered in the 
industry. For digital data, the package provides data infor- 
mation viewers, DLISView and LASView, both of which 
work in real-time. Digital converter functionality is also 
included to convert DLIS to both Log Information Standard 
(LIS) and LAS. The desktop tool package also includes 
digital data file summary listing functionality. 

More specifically, the desktop tools utility package is 
comprised of the following utilities: 

Viewer utilities to view, annotate and print log graphic 
files. Printers may be HP350C, HP450C, HP650C, HP750C, 
EPSON Stylus 1520, EPSON Stylus 3000, Printrex 820DL 
and Canon BJC-80. Proprietary printers are also supported 
when driven by WinNT4 systems. 

Converter utilities to allow PDS graphic files to be 
converted into nonproprietary formats, namely Graphics 
Interchange Format (GIF) and Computer Graphics Metafile 
(CGM). The ability to convert Microsoft Windows Metafile 
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Format (WMF) files to PDS is also included, allowing phone line), and dedicated access (connection to the SCC via 

non-log graphics to be added to a PDS file. frame relay, Tl, fractional Tl, or ATM) 106. All connections 

Data utilities for examining the DLIS data files while they to toe connectivity center are directed through firewalls 105 

are being received, and converting them real-time into LAS that are monitored for non-contracted traffic, configured to 

or LIS format. Also available are a real-time DLIS Info 5 allow the operator and their partners to access designated 

Viewer and ASCII Viewer, and a LAS certification program. hosts an d services. The use of the connectivity center 100 

Real-time viewing utilities (for example, Schlumberger's f ows x aa ac 1 uisitio11 f ite ( locat ed within an operator's 

InterACT 3.0) allow for the real-time viewing of selected Intranet) to connect to the central data hub thus facilitating 

data types (PDS, DUS, ASCII and the like) and immediate robust and effident data deliver y* 

two-way communication with the wellsite (via keyboard, 10 FIG - 9 is a diagram of the central data hub architecture 

verbal or visual). and interfaces and illustrates the workflow order processing 

FIGS. 5 through 9 show alternate configurations for within that architecture. The central data hub 110 has core 

implementing the data delivery system. The data delivery servers that su PP ort a PP lic ation execution (such as submit, 

system 60 of FIG. 5 shows a central data hub 66 and dispatch, data and archive mangers, and status servers) and 

acquisition site 61 within a private communications network 15 a PPn* ca ti° n servers that do the necessary work (such as file 

69, such as an Intranet. In this embodiment, the data transfers, faxes and the like). 

management center 64, data services center 63 and product The central data hub system 110 is divided into two major 

delivery center 65 are also contained within the private areas, front end and back end. The front end handles all user 

communications network 69. Data delivery to an operator at interaction (order preparation, submission and monitoring, 

a delivery site 62 occurs via a web data sever 68 located in 20 resource management, and administrative interfaces), and is 

a secure enclave. comprised of the web server 111 and the Interface execut- 

FIG. 6 shows a data architecture diagram of an alternate able component 112. The back end includes all the remain- 
embodiment of the data delivery system. The data delivery in S components and is responsible for executing data deliv- 
system 70 of FIG. 6 shows the acquisition site 71 and the 25 erv operations. The architecture is designed to support the 
operator's delivery site 72 within the same Intranet network creation, submission, monitoring and archival processing of 
79. The central data hub 77, the web data server 78 and the oilfield data over a variety of communication means, includ- 
product delivery center 75 are located within the same a S lobal communications network such as the Internet 
secure enclave 77. The data management center 74 and the (known as the world wide web (www)), 
data services center 73 are located within an Intranet 90. In 30 The end user, via a standard web browser, interacts with 
FIG. 6, data are transmitted to the central data hub 77 that the central data hub web pages hosted by web server 111. 
resides in a secure enclave 77 on the edge of the Intranet 90. The web server may be an Internet Information Server (IIS) 
The data are then sent to the operator at a delivery site 72 via which is a group of Internet servers (web, HTTP, FTP and 
FTP or fax, or they are made available for the operator at the Gopher) that operate with Microsoft's Windows NT server 
delivery site 72 to 'pull' from the web data server 78. This 35 operating server, or the like. These web pages on the web 
delivery can be facilitated by a physical connection from the server 111 make use of the Interface executable 112 which 
operator's Intranet 79 to the central data hub 78 or by a in turn relies on a database (such as Oracle) 113 to determine 
Virtual Private Network (VPN). what to present to the user, and to store the commands 

FIG. 7 shows a data architecture diagram of an alternate specified by the user. For example, a user will prepare an 

embodiment of the data delivery system. The data delivery 40 order t0 initiate some data delivery operations and the user 

system 80 of FIG. 7 shows the acquisition site 81 able to interacts via the web pages, the list of available data delivery 

transmit data directly to the web data server 88 which in turn options presented to the user is derived from information 

allows the operator at a delivery site 82 to access that data storeci in the database. When the user builds a data delivery 

through the web data server 88 through the operator's order > the description of the order is stored in the database 

intranet 89. In this configuration there is no access from the 45 as wel1 113 At ^nie P om t the user is satisfied with the 

data acquisition site 81 to the central data hub 86, product information contained in the delivery order, and decides to 

delivery center 85, data management center 84, data services submit it for processing. This is the critical moment when an 

center 83 which are located within their own private network order transitions from the front end to the back end; it goes 

87. In this case, data are delivered directly from the acqui- from Dem g a static description in the database to a dynamic 

sition site 81 to a data web server 88 located inside the 50 executing entity in the workflow back end. 

operator's Intranet 89. The advantage of this scenario is that The gateway to the back end is the Submit server 114. 

the operator's data does not leave its own Intranet 89. The When the user selects the Submit button on the web page 

disadvantage, however, is that delivery to partners networks hosted on the web server 110, the Interface executable 112 

or to third parties for processing or data archiving is not issues a Remote Procedure Call (RPC) to the Submit server 

immediately available. 55 114 indicating that the order is to be executed. The Submit 

FIG. 8 shows a secure enclave connectivity center 100. server 114 loads the description of the order from the 

The connectivity center 100 hosts a web data server 101 database 113, breaks up the order into the constituent tasks, 

through which operators 102 at delivery sites can access verifies that each task is properly defined (e.g. check task 

oilfield data. Operators 102 can securely access a variety of parameters for validity, etc.), and if all is proper, places each 

services through a single centrally managed connection. 60 task in the Dispatch queue 131. The dispatch queue 131 

Access can be granted to the web data server 101, which contains queues for orders to be executed (dispatched), 

may be in turn connected to an Intranet 103 through a aborted and logged. 

firewall 104. The web data sever 101 is connected to the The Dispatch server 115 services the Dispatch queue 131. 

central data hub as shown in FIGS. 1 and 3. There are a This server 115 is primarily a routing agent that takes a task 

number of methods that can be used for connecting from an 65 from the Dispatch queue 131 and, if ready for execution, 

operator's network 102 to the connectivity center 100. These places it in its appropriate application queue 118 for execu- 

include, but are not limited to dial-up connectivity (ISDN or tion by an application server 116. A task is ready for 
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execution when all its dependencies are satisfied. For 
example, a task may be setup to execute after another task 
completes, or after a specified period of time has elapsed 
(more details on dependencies will be given in the discus- 
sion on the Status server 117). 

There is one application queue 118 for each application 
server 116. These servers do the actual "useful" work in data 
delivery (i.e. transfer files, send e-mails, faxes, etc.). When 
the Dispatch server 115 places a task in an application queue 
118, it is ready to be executed. However, it still needs to wait 
for an available execution agent (thread) in the application 
server 116 to begin processing. The purpose of this arrange- 
ment is to limit the load on the system. Application servers 
116 are initialized with a fixed set of agents. Each agent can 
only work on one task at a time, and when task execution 
completes, the agent goes to the application queue to retrieve 
the next available task and begin working on it. Thus the 
central data hub HO limits the number of simultaneously 
executing tasks for each application. A description of each 
application server 116 follows. 

The converter application server 119 provides digital data 
conversion, including mapping between various file formats 
(DUS, LIS, LAS, TIFF, and the like) and data filtering 
(reducing the number of data channels in a file to customer's 
specifications). The dropbox application server 120 manages 
the publication of files to the dropbox web server, which is 
accessed by customers to retrieve data over the Internet, The 
fax application server 121 sends a graphics raster file 
generated from a PDS file to a specified fax machine. The 
FTP application server 122 sends a file to an external server 
using the FTP protocol. The notify application server 123 is 
used to send e-mail messages, with optional attachments. 
The PDS rasterize application server 124 provides data 
conversion from PDS to other graphical formats (G3 raster 
files used for faxing, GIF, CGM and the like). The print 
application server 125 sends a print request to a specified 
Product Delivery Center (PDC). The tape application server 
126 sends a tape production request to a specified Product 
Delivery Center (PDC). The real-time transfer application 
server 127 sends or receives files from a real-time server 
(such as Schlumberger's transfer express server). The trans- 
fer application server supports real-time, recoverable, effi- 
cient file transfer operations. A real-time transfer application 
server 127 is present in the data acquisition system, and in 
some data delivery destinations such as for example the 
eHub. The real-time transfer application server 127 supports 
the real-time data transfer of data from the acquisition site 
and the client delivery sites. The real-time server also 
supports data being forwarded from the central hub, if the 
destination where the data is being forwarded from is 
running a real-time transfer software application such as 
Schlumberger's transfer express. The real-time server 127 
allows establishing a real-time file transfer chain from an 
acquisition system to a real-time transfer-enabled data deliv- 
ery destination. The verify application server 128 generates 
a verification listing from a DLIS file. The listing is a 
human-readable document detailing the contents of the log 
file. 

^ Application servers 116 interact with the Data Manager 
server 129 to locate files in the central data hub system 100 
and to enter information about new files added to central 
data hub 100. The Data Manager provides access to the file 
database 113 for all applications. For example when a file is 
uploaded into central data hub 100, the real-time transfer 
application server 127 notifies the Data Manager 129 and 
includes the context in which the file was uploaded. The 
Data Manager 129 stores information about the new file in 
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the database 113. When an application server 116 such as 
Fax 121 wants to locate a file (e.g. a G3 raster file), it 
communicates with the Data Manager 129 as well: it gives 
the Data Manager 129 the unique ID of the file and receives 

5 the full information about the file, including its location in 
the file system through the Data Manager 129. The Data 
Manager 129 together with the Archive Manager 130 man- 
age file data uploaded to the central data hub 100 or 
generated at the central data hub via file conversion appli- 

3Q cations. 

The Status server 117 is responsible for maintaining task 
status and supporting task dependencies. Every task in 
central data hub 100 goes through a well-defined set of states 
as it progresses through the workflow of the system. This 

15 state is visible in the user interface and is used heavily for 
monitoring and administration. As each application server 
116 handles a task, it sends a message to the Status queue 
notifying the Status server 117 that a task has entered a 
particular state. The Status server 117 reads the message 

20 from the Status queue and updates the database 113 with the 
new task state information. The Status server 117 also 
updates the task status with other kinds of information, such 
as messages and progress reports. This information also 
arrives from various servers through the Status queue. In 

25 addition to keeping up the task status, the Status server 117 
supports task dependencies. When a task is received by the 
Dispatch server 115 and it has an unsatisfied dependency, the 
Dispatch server 115 discards the task message and sends a 
message to the Status queue indicating that a task is waiting 

3 Q for a dependency to be satisfied. The Status server 117 keeps 
track of all tasks that are waiting for dependencies, and will 
place them back into the Dispatch queue 131 when the 
dependency conditions have been met. 

In addition to task dispatching, the Dispatch server 115* 

35 also supports log messages. The central data hub 100 keeps 
detailed logs of all activity in the system in the form of text 
files. The generation of these text files is centralized in the 
Dispatch server 115. The Log queue as part of the Dispatch 
queue 131 is used by all system components to notify the 

40 Dispatch server 115 when a message needs to be placed in 
a given log file. The Dispatch server 115 reads from the Log 
queue and routes received messages to the appropriate file. 

The Archive Manager server 130 handles the exporting of 
files to archive systems. The Archive Manager hosts special 

45 archival applications that export file data from the central 
data hub to external databases. For each archive system type, 
there is an agent in the Archive Manager server 130 that 
periodically scans the central data hub database 113 for new 
files to be archived. It sends a message to the archive system 

50 130 describing the data and then transfers the files. 

FIG. 10 is a table of central data hub external interfaces. 
The data acquisition system interfaces 151 between the 
central data hub include a we b browser 152 that interface s 
with the web server and is used to navigate the web pages 

55 a nd a real-t ime transfer ser ver 153 interface that interfaces 
wuh the reai-iime ira nsi er application server and is used to 
upload/d ownload tiles in near real-time TThere are data 
delivery sysiem interlaces to the central data hub 154. An 
FTP server interface 155 interfaces with the FTP application 

60 server and is used to deliver files using an FTP protocol. A 
Simple Mail Transfer Protocol (SMTP) server 156 interfaces 
with the Notify application server and is used to deliver 
messages and file attachments as e-mail. The fax machine 
interface 157 interfaces with the fax application server and 

65 is used to deliver graphics. The Product Delivery Center 
(PDC) interface 158 interfaces with the print, tape and CD 
application servers and is used to produce and deliver hard 
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media (tapes, prints, CD's) to customers. The web server options: send, select or task output and can select the output 

159 interfaces with the web application server and the web graphics conversion format. 

dropbox application server and is used to deliver data to the FIG. 20 is an architectural diagram of the eHub. The eHub 

customers over the web. 240 accepts data from data originators 241 (such as client 

FIG. 11 is a flowchart of the submit server processing $ delivery sites, data acquisition sites, the central data hub and 
within the central data hub. In the submit server processing we like ) and transfers data to data delivery sites 242. The 
170, if the workflow order is a submission request 171 graphical user interface provides a view into the eHub 
received from the interface executable, the workflow order database 244 that contains a data catalog of the database 
transmission is validated for integrity 172. The workflow contents and file system 245. Individual user applications 
order is broken into its constituent tasks 173, including the 10 can develop application specific views which can then be 
task parameters and any task dependencies. Task dependen- integrated into the eHub framework. Most user interfaces to 
cies could include waiting for a certain time to process the ^ eHub with the exception of some administration 
workflow orders that are placed on the dispatch queue 174. tooJs > are web-based interfaces. The primary means for 
If the workflow order is a task abort request 175, the locating data at the eHub is through a hierarchy that corn- 
workflow task abort request is validated for integrity 176 15 prises a folder organization similar to that used by 
and placed on the abort queue 177. Submit processing ends Microsoft's Windows Explorer. The eHub 240 defines the 
178. top levels of the hierarchy with sub-trees refined by the 

FIG. 12 is a flowchart of the dispatch server processing. req™ents of the applications. The eHub database and its 

In the dispatch sever 180, messages in the dispatch, abort catalo S c u an * i earch f d b L* s ™ c « e ° e L me since every data 

and log queues are processed 181. If the message is a 20 Hem in the eHub catalog 244 is defined by a set of attributes 

dispatch 182, the message is routed to the appropriate wh 1C h vanes for each data type Using the search interface, 

application queues for execution 184. If the message is a log a , ^ 15 , ab ! e t0 s P eclf y values for vanous ^butes. After 

message 185, the message is written to the appropriate log me s * arch J ls Emitted, * result list is presented with all 

file 186. If the message is an abort task message 187, the task matching data items. If a matching item is a folder, it is 

file is deleted 188. Processing ends step 189. 25 P 0SSlbk t0 navi S ate ^ hierarchy below it from the search 

FIG. 13 is flowchart of the status server processing. In the N°n-folders will be displayed as regular items with 

status server 200, the status queue is processed which , Mnbu * s and be downloaded when selected, 

includes processing task state transitions, task messages and Selec , bn 8 aflle f a * a ltem '.« lther ™ «» hierarchical or the 

task statistics 201 . The status server maintains task and scarch t ?' cs » 1 ^f C6 ' ** , ac to * do ™^ adcd 

workflow order state statistics 202. It identifies tasks waiting 30 the HT1TS P° rt If 1 f stomer * as established 

r oir . o . rtt , , , . . . n ... _ n , J* file associations in his/her web browser, the appropnate 

tor events such as task and order state transitions and timer .„ , . 4 . . , ' ri ™* £1 • 

„ ,„ lt i *u * i j ■ A* application will be automatically launched after the file is 

events 203. It places the task messages in dispatch queue / ij JA • t_. 

i 4. i jt j • , . * nA f • downloaded. A preview feature (showing a subset or 

when task dependencies are complete 204 and processing , , . £ iL - A 4 , ' K ^ „. 5 L . A . . . 

ends 205 reduced image of the data through the Web interface) is 
' . ... . , .. .35 included as well as a catalog view feature (either hierarchi- 

. ■ ?'k * ' , laeram 2? \ « r ? ffi fe 0B main : cal or search) which displays data attributes and aids in data 

tamed by the status server. The task states include created y^m^ni In to file data it me eHub hier . 

210, submitted 211, pendmg 212 waitag 213, aborted 214 interfac6 ^ host ^ (o Kcations . ^ K . 

STI SUSpended 216, Sklpped 217 ' Wntmg 218 311(3 nation is defined as a set of web pages and/or associated 

h I . o . , ■ . .^o server and/or client side code that implements business 

FIG 15 is a diagram of the order state transitions main- line-specific navigation and/or behavior. The eHub has a 

tamed by the status server. The order states include created uscr mtcrfacc ( web . based) that ^ acccss to tae following 

220, intervening 221, incomplete 222, in progress 223 and features: addin g a new data ilem or folder to the eHub 

ctone 224. catalog, specifying attributes and optionally access control, 

#«T FTG. 16 is an exemplary display of a user inierfacj for 45 a nd transferring the data (e.g. files) from the publishing 

/ ordering and submitting a workflow order. The user interface system f rom me eHll b; modifying the attributes or access 

# 230 displays aiist of tasks, gives access to parameters and CQnivo \ 0 f an existing catalog data item or folder; moving a 

I dependencies for each task in the workflow order and gives data i tem or f 0 i der from one place in the hierarchy to another 

f access to order submission. and rem0 ving a data item/folder from the catalog (removing 

FIG. 17 is an exemplary display of a user jnterface for 50 a folder will implicitly remove all items under it). The eHub 

specifying and displaying task dependencies for tasks in the will provide through its user interface access to several user 

workflow order. The user interface 235 displays a. list of task support features: documentation and site guides, on-line 

dependencies that affect the time when a task is executed. It help, technical support gateways (e-mail, phone, etc.) and 

may incluae three types of dependencies: task where execu- problem reporting. 

tion is delayed until a given task enters a specific state; order 5S xh e publishing server 246 allows for the entering of new 

where task execution is delayed until a given order enters a data deS criptions into the eHub catalog, physically moving 

V specific state; and time where task execution is delayed until me data (e.g. files) to the eHub system, and manipulating 
a specified duration elapses. existing entries in the catalog. This process is carried out 
FIG. 18 is an exemplary display of a user interface for through the publishing interface, which governs the inter- 
specifying data conversion for the workflow order 236. The $o action between the Data Originator 241, which supplies new 
user can select the input file form three available options: content or modifications, and the Publish Server 246, which 
send, select or task output. The user can select the output is the entity responsible for entering the information in the 
format, select a company specific filter and specify any catalog and/or manipulating it. The publishing process is 
special format parameter changes. divided into several steps. All messages from the Data 
FIG. 19 is an exemplary display of a user interface for 65 Originator 241 to the Publishing server 246 are normally in 
specifying graphics conversion for the workflow order 237. Extensible Markup Language (XML) format, except for the 
The user can select the input file from three available actual data transfer. A context query is an optional step, 
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which may be used by the Data Originator 241 to get is through the use of Proxy Servers. A Proxy Server is simply 

information about the eHub catalog; i.e. what folders are an agent that relays specific protocol traffic (typically only 

available (wells, customers, and the like). This information HTTP and FTP) between a client and a server, 
can be used to facilitate human interaction (for example, to 

display a hierarchy to be published into). It can also be used $ Operating System and Web Server Hardening 

to monitor the state of items in the catalog (number of bytes, „ , r 14 K ™ „ c , 

• j i j c i_ j . \ ,/ ' By default. NT Servers are not configured as a secure 

whether data transfer had errors, etc.). The query result is an / . . , , . T * * • * t *u* 

, . , . * r.t_ • , , system that can be placed in the Internet environment. In this 

optional step that carries the results of the query back to the 4 . * t * . . . ... 

i u^r™ / ... - respect, it is no different from other operating systems that 

Data Originator 241. The publish request is a description of j . , . . t . . . r T . °, ' . 

iL , , , x 4 , , r t iL * j * ate designed primarily to operate m the Intranet, and are not 

the data item(s) to be published, for example, the meta-data. in „ . f r . , J , f, r ., : . . 

T . t , .V *• u * l • «{. V- l i_ setup by default to deal with many of the threats present m 

It includes information about where m the hierarchy each . . , , ' _ ... A .„ . r , , . 

" . , * j 4 l * j , ' 7\ uiviaiviij va.u lhe external netW0 rk. The process of identifying and closing 

item is located, the item data types and the set of associated 4 . . n r CJ( lt « ? ■ n j 

„ t y 4 i * ... the security gaps in the OS default configuration is called 

attributes. In a non-transactional request, items that are . . • ^ . u - u i a i 

- j * * ^ j * . OS hardening: . Web servers, which are layered network 

error-free are entered into the catalog, and the ones m error .... , • « £ * r 

j . , , iL ~ , ^. • . ^ , appucations. also need to be especially configured for secu- 

are reported back to the Data Originator 241. Yet another ™ „ . . , . ♦ * n , * .u 

. " .,1^.1.^ „, . ■ . -.i . . nty. The eHub proiect has procedure to follow to strengthen 

mode is provided, Publish Proposal , which will not enter , u K ™ , T f c •* r i *u i r 

. r t . . . , ™ . . , t the NI and IIS security frameworks, with the goal of 

any information in the catalog. This can be used to pre- . t . »* i t-l- , .„ . 

i*j * U1 l ? ' j. ' *" resisUng many common attacks. This procedure will be 

va Mate a publish operation In addition to entering new ^ Qn ex ^ M ^ Sccurc 

data, pubhsh requests can also modify existing data e.g. ^ {q , ntranets [o deUvef daU tQ ^ eRub yia ^ 

change the attnbutes of an existing request, creating a folder, 9n j , l l • . j . . • , r , , „ ■ , ., , , 

.... ., . . . . " , . . '.^ . f / data nub may include deploying Virtual Private Networks 

deleting an item, etc.). This is done by identifying the item(s) rvPNsI 

to be modified (e.g. by unique ID), and a description of the , . , „, . 
requested modification (change of attributes, access control, Users " e authenticated to the eHub by supplying auser 
parent container, etc.). The request result is a message that ° ame an f, P«™». wh«* will be encrypted in HTTPS. 
contains a per-item publish result (success or failure, and if M Users W1 A U t0 ^thenticate once at the beginning of a 
failure, a human-readable description of the reason). In the sess J 0D - As u lon 8 35 a ^ion remains active the user will not 
data transfer step, the originator transfers the file(s) associ- ne ? d 0 authenticate again. A se^ion may be terminated due 
ated with the publish request. The transfer monitor follows 10 ^ ° f **"*y ( e S" "° HTTP requests in 20 minutes), or 
the progress of the data transfer in order to respond to failure explicitly by the user through the web interface. The user 
conditions, or to signal events. Standard protocols may be 30 dat ^»f ^ JfP» f ' he L^tweight Directory Access Pro- 
used (such as HTTP, FTP and the like), but for real-time data toco1 (LDAP) 248 that is a network protocol for accessing 
transfer the only option currently available is a company Rectory repositories. 

proprietary software application such as transfer express. Ml published data is access-controlled. Administrators 

Whatever the protocol, it must support authentication, since and publishers cooperate to specify who has access to the 

publishing operations will be access controlled. 3S data - ^ basic access model fe the following: when a user 

Security features of the eHub 240 may be deployed in two authenticates, the eHub determines what groups the user 

distinct types of configurations: Internet and Intranet acces- bcioa ^ «"> ( this ^formation is kept in LDAP 248). 

sible. In the Internet accessible configuration the eHub 240 Resources (folders or files) are tagged with an access control 

is located in an enclave providing the following services: hst ( ACL )> wmch * l m^y a fist of groups. When the user 

access from the Internet, protected by firewalls that restrict 40 a,tem P ts t0 ff? 8 a J? 50 "/"' thc L cHub conl Pares the user 

traffic to known ports/protocols (for example HTTPS; note 8 rou P llst Y lth the ACL - If a matchmg entry exists, the user 

that these firewalls would not be configured to do 15 assumed t0 have access to the resource - A ^source's 

IP-address-based filtering) and detect common attacks such visiMily wdl be controlled as well: a user will not see m the 

as denial-of-service; direct connections from customer's mterface an y ^sources to which the user does not have 

networks via dedicated high-bandwidth links, and dial-up 45 access * 

access, protected by firewalls in a manner similar to the Access control is simple yet flexible. The eHub does not 

Internet connection; and access from company proprietary require that a human explicitly set access control for every 

Intranets, also protected via screening firewalls. Users published item. To facilitate this, the eHub takes advantage 

(customers, administrators, and the like) do not need to of the organizational hierarchy to provide default ACL's. 

authenticate to the enclave, only to the eHub (for example, 50 For example, a file resource may not have an explicit 

an anonymous web Internet connection should be allowed to associated ACL. In this case, when a user attempts to access 

reach the eHub, which will perform authentication at that the file resource, the eHub will determine accessibility by 

point). The Intranet accessible configuration is available for looking at the ACL of the parent folder. If the parent also 

customers who do not find the Internet option acceptable does not have an explicit ACL, the process is repeated up the 

because the customer is not satisfied with the security 55 ancestor chain until an ACL is found, or a root element is 

measures, finds Internet access inconvenient, or has a strong reached. 

network infrastructure with poor Internet connectivity. In For data privacy, traffic to/from the eHub 240 will be 

any case, the eHub will be installed in the customer's encrypted using industry-standard HTTPS. The business 

Intranet, to be accessed only from within the customer's objects 249 manage the eHub data. _^ 

network. 60 Real-time data delivery is handled in the eHub 240 by the 

System and network security can be accomplished by real-time data server 249. There are two aspects to real-time 

separating the data and application repository from the data delivery. First, on the server side, real-time implies that 

system that is physically outside of the Intranet network. In the content being delivered is not static (such as a web page 

this configuration, the system that is externally accessible is or a Word document), but is generated incrementally based 

only a "front" for the "real" eHub, which is located in an 65 on information continually provided to the web server. This 

Intranet, benefiting from the Intranet security features. An can be understood as a dynamic content generation engine 

industry-standard approach for achieving this configuration (e.g. CGI, ASP, or Java Servlet^ that is reading information > j 
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from a continuously-updated source (e.g. a growing serial 
file, or a database) and passing it on to the client over the 
HTTP(S) stream. Second, on the client side, real-time 
implies that the HTTP(S) stream is made available as it is 
received to a client-side application or component (such as 
a log viewer, or numerical display). 

Akey feature of the above system is that data is serialized 
before being delivered to the client. This implies not only a 
serialization component on the server side, but also coop- 
eration between the producer and the consumer of the 
stream. For certain types of data, such as serial files, 
serialization is a trivial task. Other sources, like databases, 
could require significant design work. 

Th eHub provides two solutions. It defines the architec- 
ture for delivering a data stream from the eHub to the 
customer's desktop in a secure manner. The architecture 
consists of the following: 

a server-side interface for stream providers. An applica- 
tion implements this interface to serialize server-side 
data; 

a means of identifying a server-side data provider (for 
example, database, serial file, numerical status, etc.) in 
the URL; 

a single implementation for determining access control to 
stream sources, based on information contained in the 
URL, so applications do not have to implement their 
own access control checking; 

support for HTTPS as the transport protocol, to provide 
data privacy; 

centralized logging of data access for security auditing 
purposes; and 

a client-side (web-browser-hosted) interface for stream 
receivers. An application would implement this inter- 
face to handle the serialized stream and take appropri- 
ate client-side action (for example, write to a file, 
^ update a numerical display, etc.). 

Based on this infrastructure, the eHub provides a set of 
implementations that will allow delivering a serial file in 
real-time from the eHub to the customer's desktop, follow- 
ing the read -while-write (RWW) protocol, and launching a 
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client-side application that can make use of the real-time file 
faich as HPS Vie w! "" 

Specific Application Hosting includes supporting web 
data delivery in real-time. Application code will be able to 
register for event notification and processing, and for execut- 
ing handling code. For Web data delivery (WebDD), the 
event of interest is when a WITS data item is added to the 
catalog and the action is to prepare the WITS receiver for the 
new data. This processing occurs in the WITS server 250. 
The notification includes references to the physical data item 
(file specification) and to the meta-data. The event notifica- 
tion model allows any application to listen for significant 
eHub events and react accordingly. The eHub application 
framework will include an interface for obtaining the end 
user identity (user name, LDAP attributes, etc.). 

Applications are able to use the infrastructure. In 
particular, WebDD is able to query the eHub for resource 
permissions. At a basic level, the eHub exposes access 
control of resources it knows about. An application will be 
able to ask whether a user has access to a file, and the eHub 
implements the lookup algorithm. A more general approach 
is to allow an application to create its own access controlled 
resources, and have them managed by the eHub access 
control system (for example, data channels inside WebDD). 

Applications are visible as links in the eHub hierarchical 
view of the catalog, perhaps even becoming actual catalog 
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entries. These links need to have enough information (e.g. 
via URL parameters) so that when the application is 
launched, it has all it needs to know to provide the user with 
the desired view. The information needed to launch an 
application such as WebDD (URL, parameters that need to 
be passed, etc.) will be stored in the catalog entry for the 
application. 

The central data hub is one of the primary sources of data 
for the eHub 240. As such, it is adapted to interface to the 
eHub as a data originator. An "eHub" application is added to 
the central data hub that allows the placing of files (either on 
the data acquisition system or at the central data hub) into an 
eHub publishing request. The request will include additional 
information, such as metadata required in the publishing 
interface. The validation step of the central data hub/eHub 
application will be a "Publish Proposal" request to verify the 
meta-data description is correct (for example, well name, 
customer, etc.), which should increase the likelihood of an 
error-free publication. The active request will be issued in 
the central data hub/eHub application runtime, which will 
act as the data originator. Results of the publish request will 
be used to determine the central data hub task state, which 
will allow user intervention when necessary. Data transfer 
will follow the publish request using a protocol such as a 
company proprietary software application such as transfer 
express. 

The eHub contains two types of administration interfaces: 
those that are embedded in the user views, and those that are 
part of special tools. Embedded interfaces include, for 
example, ACL management, which could be presented as 
additional, administrator-only, items in the standard hierar- 
chical catalog view. The eHub provides administrator user 
interfaces for creating, modifying and deleting user entries. 
It allows for the management of user groups and associating 
them with user entries. An account creation request is started 
with the potential new user submitting a form to the eHub 
that contains all the information required to create the 
account. The request contains a reference to an agent trusted 
by the eHub administrator. The eHub administrator receives 
the request (e.g. via e-mail) and verifies the information with 
the trusted agent, revising it as needed (e.g. group 
membership), and creates the account. Users manage their 
own passwords. Password checking is supported (minimum 
length and enforce numeric characters). The main features of 
content management are access control, quality maintenance 
and data offloading. Administrators will be provided with a 
user interface for viewing and setting access control on any 
eHub resource. The interface will allow the administrator to 
select any resource (well, bit run, file, application, and the 
like); it will show who is the owner of the resource, which 
groups and users have access to it, and what type of access 
they have. It will also show whether the access control is 
explicit on the resource, or whether it is inherited from a 
folder. Administrators are able to add/remove groups from 
an explicit access list, remove an access list (so that access 
is derived from the folder), or create an access list if a 
resource does not have one and manage access through a 
password change utility. Resource editors allow users to 
create, edit and delete resources such as customer, well and 
fax machine. It allows the eHub administrators to create, edit 
and delete resources such as the dropbox, eHub, data center 
and transfer resources. The change context utility allows for 
the modification of the company /well focus in the session to 
the central hub. A user editor allows administrators to create, 
edit and delete user records. A cleanup utility allows admin- 
istrators to archive old order records and remove file data 
from the system without the loss of an audit trail. A change 
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applications utility allows administrators to customize communicating with multiple remote delivery site 

which applications are available in the user interface for a computers for the simultaneous display of the oilfield 

given central eHub. The change fax routing allows admin- data in near real time_ at the multiple delivery site 

istrators to determine the origin of the fax deliveries, either computers in response to the workflow order. ~% ft mJ 

form the central hub or a remote fax unit of the eHub. The 5 2. The system of claim 1 further comprising a workflow ■ ■ ^ 

server manager allows administrators to control the back end order generating module in the central data hub computer 

servers of the eHub. that allows a user to generate and submit the workflow order 

Quality maintenance activities include revising attributes to the central data hub computer for processing. „ 

of published data, moving content within the hierarchy and 3. The system of claim 2 further comprising a workflow* 

removing content. Administrators are provided with a user 1Q order status monitoring module in the central data bub 

interface to accomplish these tasks. This user interface will computer that monitors the status of a submitted workflow^ 

in turn interact with the publishing application interface order, 

catalog modifications. 4 ^ svstem of claim 1 comprising a data 

Data offloading is the removal of catalog entries and services cente J com P uter f° r Post-acquisition oilfield data CLoCC«ina 

freeing-up of associated resources (files, etc.). Administra- 15 processing the data services center computer bemg in £-J' (C ^d>NS 

tors are allocated tools for performing manual removal, and 15 commutation wim to ^ 

c * ♦ J T c * ■ u a 5. The system of claim 4 further comprising post- 

for configurmg automated removal of entries based on uisition J afldd data p rocessing softwa re applications 

attributes (age, size, last lime accessed, etc.). ^ me da(a wxyjm ce k r computer, the software appli- 

Using the foregoing, to invention may be implemented cations being selcclcd from ^ group consisting of borehole 
using standard programming or engineering techniques 20 seismic applications, borehole imaging applications, petro- 
including computer programming software, firmware, hard- physics applications, well test applications, production engi- 
ware or any combination or subset thereof. Any such result- neering processmg applications and interpretation function- 
ing program, having a computer readable program code applications. 

means, may be embodied or provided within one or more 6 ^ system 0 f claim 1 further comprising an oilfield 

computer readable or usable media, thereby making a com- 25 data archival database in communication with the central 

puter program product, i.e. an article of manufacture, data nil b. 

according to the invention. The computer readable media 7 ^ system of clajm x wherein the data com . 

may be, for instance a fixed (hard) drive, disk, diskette, prises a File Transfer p rot ocol (FTP) data server for trans- r 1 r 

optical disk, magnetic tape, semiconductor memory such as miuiQg oilfield data tQ at least 0Qe remote delivery site 

read-only memory (ROM), or any transmitting/receiving 30 computer. 

medium such as the Internet or other communication net- g system 0 f c i a j m \ wherein the data server corn- 
work or link. The article of manufacture containing the prises a global communications network (" web"") data server 
computer programming code may be made and/or used by capable of transmitting oilfield data in near~real-time to the jOe)QSe>WCr 
executing the code directly from one medium, by copying multipk remote delivery sitc computers via a global com- 
the code from one medium to another medium, or by 3S mun ications network. 

transmitting the code over a network. 9 ^ systcm of daim x whcrcin the data scrver com . 

An apparatus for making, using or selling the invention prises a real-time data server for transmitting oilfield data to ^jj^jl 

may be one or more processing systems including, but not multipirSelivery site computers in near real-time via a third ^SJl t » Ot^ 

limited to, a central processing unit (CPU), memory, storage communications network. 

devices, communication links, communication devices, 40 10 ^ system of claim 9 wherein the third communica- 
server, I/O devices, or any sub-components or individual tions networ k comprises a communications link and a com- 
parts of one or more processing systems, including software, munications protocol. 

firmware, hardware or any combination or subset thereof, n ^ system of c]aim 10 wberein ^ third communi- 

which embody the invention as set forth m the claims. cations networ k is a global communications network. 

User input may be received from the keyboard, mouse, 45 12 . The system of claim 10 wherein the communications — -p A 0 

pen, voice, touch screen, or any other means by which a prot ocol is Transmission Control Protocol/Internet Protocol 1^7 1 r 

human can input data to a computer, including through other (TCP/IP). 

programs such as application programs. 13 ^ system of claim 9 whe rein the communications | 

Although the present invention has been described in pro t 0 col is HyperText Transfer Protocol (HTTP). KtTp 

detail with reference to certain preferred embodiments, it 50 14 system of claim 9 wherein the second and the 

should be apparent that modifications and adaptations to ^ commun i ca tions networks comprise a real-time com- 

those embodiments may occur to persons skilled in the art mU nications transfer protocol. 

without departing from the spirit and scope of the present 15 ^ system Qf daim 9 wherein me mird ^^i^. 

mvention as set forth in the following claims. ^ons network comprises a real-time data transfer capability 

What is claimed is: S5 using a HyperText Transfer Protocol (HTTP). 

1. A data delivery system for delivering oilfield data from 16 ^ system of claim 2 where in the first communica- 

at least one data acquisition site to a remote delivery site, Uons network CO mprises a satellite c ommunication network, 

comprising: 17 The syslem 0 f c ] a j m i w hcrein the first communica- 

a. a central data hub computer that processes a workflow ii ons network comprises a telephon e communication net- 
order that controls delivery of oilfield data from the at 60 WO rk. ^ - 

least one data acquisition site to a remote delivery site; is. jhe system of claim i wherein the first communica- 

b. a data acquisition site computer that transmits oilfield tions network comprises a microwavetransmission network, 
data over a first communications network to the central 19. The system of claim 1 wherein the first communica- 
data hub computer in near real-time in response to the tions network comprises a radio c ommunication network, 
workflow order; and 6S 20. The system of claim 1 wherein the first communica- 

c. a data server that receives data from the central data hub tions network comprises a wireless telephone communica- 
over a second communications network, the data server tion network. 
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21. The system of claim 1 wherein the first communica- 37. A computer-implemented method for near real-time 
tions network comprises a TCP/IP communications proto- data delivery of oilfield data from at least one data acqui- 
col. sition site to a remote delivery site, comprising: 

22. The system of claim 1 further comprising a hardcopy . t a j t , , t , , 
, ; . . . . r*u -i j i~j j ^ a. processing a workflow order at a central data hub 
deliv ery cente r, that generates a hardcopy of the oilfield data 5 v 6 . , , _ , t _ . 
as controll e d by the workflow order from the central data computer that controls delivery of oilfield data from the 
hub, in communication with the central data hub. a f least 0DC data acquisition site to the remote delivery 

23. The system of claim 22 wherein the hardcopy is stored site; 

on media selected from the group consisting of a hardcopy b. transmitting oilfield data over a first communications 

report, a taoe, a film and a_CD-ROM.^ 3Q network from a data acquisition site computer to the 

TT. The systenfoTclaim 1 wherein the central data hub data hub computer m near real-time in response 

comprises: t0 ihe workflow ordcr; 

a. a user interface module that receives a user generated 

workflow order for oilfield data; c " scndlD g 0llficld data from mc ccntTal data hub t0 a data 

b. a submission module that loads a description of the over a communications network; and 
workflow order and breaks the workflow order into at d. receiving data from the central data hub at the data 
least one task containing task parameters and task server, the data server having the capability of corn- 
dependencies and transfers the task to a dispatch mod- municating with multiple remote delivery site comput- 
ule for routing the task; ers for the simultaneous display of the oilfield data in 

c. at least one application module that executes the routed 20 near real time at multiple delivery site computers in 
task; response to the workflow order. 

d. a status module that maintains the task dependencies 38. The method of claim 37, further comprising allowing 
and monitors task status* a uscr 40 generate and submit the workflow order to the 

e. a data manager module that enter soilfield data in a central data hub computer for processing using a workflow 
database accessible by the central data hub; and 2 5 ordcr S encratin e module in ^ central data hub computer. 

f. an archive manager module that handles the export of . 39. TT» method of claim 37 further comprising monitor- 
. , 4 . - b . . , ine the status of a submitted workflow order using a work- 
information for archival. _ & , A A , . . , , . . r, . , , 

™ . r i . Air iU _ flow order status monitoring module in the central data hub 

25. The system of claim 24 further composing a real-time & 

data transfer module for transmitting real time data as C ° m i )l !4 r ' • • ^ 

t • ,1 , c j . . „ rt 40. The method of claim 37 further comprising perform- 

specified in the workflow order from a data acquisition site 30 . t ... , . , 4 • ♦ 5 ♦ ™ 

to a data delive site P 051- ^^ 11100 oilfield data processing at a data ser- 

26. Tie sJS, of claim 25 wherein the real-time data vices «f er ^ u{ct which fa * comm^nicatioQ with the 

transfer module comprises a transfer express communica- CCI l? a r I , a a , , . . . . , - ■ 

. . . r 1 r 41. The method of claim 37 further comprising archiving 

Tl^Z oTSal 24 wherein the user-interface 35 ^ " ^ daUbaSe iQ "™™ cati ° n **» 

module interfaces with a web browser for receiving t he *™ J u ^ ^ 3? ^ rfsi transmi( . 

workflow order. , , . A . , x . • *l j * * *u 

* 0 ™ . c , . * A , . r ting oilfield data in near real-time via the data server to the 

28. The system of claim 24 wherein the application * . , t . . t t , , . 

i i • , t . (• a- ( L j multiple remote delivery site computers via a global corn- 
module comprises a data converter function that provides * J r °^ 

digital data conversion and data filtering of oilfield data as 40 m^^ons network. . 

•c j • i n j 43. The method of claim 42 wherein the data server is a 

specified in the workflow order. , . . ... , /ti . . 

*\ ft . c , . - A . • tk !■ global commumcations network ( web ) data server. 

29. The system of claim 24 wherein the application * c . t ^ u 7 . . . 

, . ^ . - - rr 44. The method of claim 37 further comprising transmit- 

module comprises a fax function. . . 1C , , , . ... P _ r.™ j * 

* r 1 • u ■ »u r ** tine oilfield data m near real-time from a real-time data 

30. The system of claim 24 wherein the application e 4i . u- i j v * * * *u- a 
j 1 • Li- u- *u 'ifi-u A«* n a „™k server to the multiple delivery site computers via a third 

module comprises publishing, the oilfield data to a web 45 . . f , 

a j • ,1. i a j„ communications network- 
server as specified in the workflow order. m_ ^ * c i • aa c ^ • • j* 

31. The system of claim 24 wherein the application 45 ' ^hod of c la,m 44 further compnsing a data 
module comprises sending the oilfield data as specified in «*ion ^uk for compressmg data transmitted over 

„ ua~Z ,r. „, ,i „„,„, „„:„„ ,„ tm> the first, second and third communications networks. 

^oto^f so 46 ' ^ method of claim 37 wherein ^ 6151 communi - 

^M.^The system of claim 24 wherein the application »*?» QCtwork 45 f ^d from the group consisting of a 

, . J . j . . * satelhte communication network, a telephone commumca- 

module comprises sending e-mail messages to a computer . , . * • • . i j- 

server as specified in the Workflow order Uon network ^ a microwave transmission network, a radio 

33. The system of claim 24 wherein the application communication network and a wireless telephone commu- 
module comprises a data conversion function for converting 55 nicaUon networ * 

i • j t • j ■ ( i , r, 47. The method of claim 37 further comprising, in accor- 

graphics data as required in the workflow order. . ... , *\ 

. « i u • »u* r«««* dance with the workflow order, generating a hardcopy ot the 

34. The system of claim 24 wherein the application „„ , , t , , A • • t . 

i i ■ a *• f ^- u«^™w™„«* oilfield data at a hardcopy delivery center in communication 

module comprises a function for sending a hardcopy request . , , , , . / 

j . . i* t with the central data hub. 

to a product delivery center. ^ ^™ . , c i - ^» L . 4 , 

35 The system of claim 24 further comprising a real-time 60 1116 ^? Cth ° d ° f daim ^ rcm P roccssin g thc 

application module in communication with the central data workflow order at the central data hub uprises: 

hub for sending oilfield data in real time from the data a. receiving a user generated workflow order for oilfield 

acquisition site to multiple remote delivery sites. data at the central data hub; 

36. The system of claim 35 wherein the application b. loading a description of the workflow order and break- 
module comprises a real-time oilfield data transfer function 65 ing the workflow order into at least one task containing 
that sends data to and receives data from the real-time task parameters and task dependencies and transferring 
module. the task to a dispatch module for routing the task; 
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c. executing the routed task; 

d. maintaining the task dependencies and monitoring task 
status; 

e. entering oilfield data in a database accessible by the 
central data hub; and 

f. handling the export of information for archival. 

49. The method of claim 48 wherein the user generated 
workflow order is received by a user-interface module 
interfacing with a web browser. 

50. The method of claim 48 wherein an application 
module executes the routed task. 

51. The method of claim 50 wherein the application 
module comprises converting digital oilfield data and filter- 
ing the data as specified in the workflow order. 

52. The method of claim 50 wherein the application 
module comprises publishing the oilfield data to a web 
server as specified in the workflow order. 

53. The method of claim 50 wherein the application 
module comprises sending the oilfield data as specified in 
the workflow to an external server using an FTP protocol. 

54. The method of claim 50 wherein the application 
module comprises sending e-mail messages to a computer 
server as specified in the workflow order. 

55. The method of claim 50 wherein the application 
module comprises sending a hardcopy request to a product 
delivery center. 

56. The method of claim 50 wherein the application 
module comprises sending oil field data in near real-time 
data from the data acquisition site to the multiple remote 
delivery sites. 

57. The method of claim 46 further comprising sending 
oilfield data in near real-time from the data acquisition site 
to the multiple remote delivery sites as specified in the 
workflow order. 

58. The method of claim 48 further comprising a built-in 
data recovery module in the central data hub for recovering 
data if the transmitting of the oilfield data from the data 
acquisition system to the multiple remote delivery sites fails. 

59. A software program embodied on a computer-readable 
medium incorporating the method as recited in claim 37. 

60. A method in a computer data delivery system for 
delivering oilfield data from at least one data acquisition site 
to multiple delivery sites comprising: 

a. receiving a workflow order for oilfield data at a central 
data hub computer; 

b. executing the received workflow order at the central 
data hub computer comprising: 

i. if the task parameters are valid, submitting the task 
for dispatch comprising: 

1 . loading the description of the workflow order; 

2. breaking the workflow order into at least one task 
containing task parameters and task dependencies; 

ii. if task dependencies are satisfied dispatching the task 
for execution; 

iii. executing the task; and 

iv. monitoring task status. 

61. The method of claim 60 wherein submitting the task 
comprises: 

a. receiving a workflow order request at a submit server 
within the central data hub; 

b. validating the workflow order; and 

c. placing the workflow order on a dispatch queue. 

62. The method of claim 60 further comprising if the 
workflow order is a task abort request: 

a. receiving a workflow order request at a submit server 
within the central data hub; 



L9,568 Bl 

32 

b. validating the workflow order; and 

c. placing the workflow order on an abort queue. 

63. The method of claim 60 wherein dispatching and 
executing the task comprises processing tasks in a dispatch 

s queue by routing the task to an appropriate application 
server for execution. 

64. The method of claim 63 wherein the application server 
comprises a digital data conversion and filter application. 

65. The method of claim 63 wherein the application server 
ao comprises a web dropbox server for sending data to a web 

server. 

66. The method of claim 63 wherein the application server 
comprises a fax application server for sending the oilfield 
data to a fax machine. 

67. The method of claim 63 wherein the application server 
15 comprises a file transfer protocol (FTP) server for sending 

files to a server external to the central data hub using FTP 
protocol. 

68. The method of claim 63 wherein the application server 
comprises a PDS rasterize application server for converting 

20 data from PDS graphical formats to other graphical formats. 

69. The method of claim 63 wherein the application server 
comprises a hardcopy server for sending a hardcopy requests 
to a product delivery center. 

70. The method of claim 59 wherein the application server 
25 comprises a real-time transfer application server that sends 

data to and receives data from a real-time server. 

71. The method of claim 70 further comprising a second 
real-time transfer application server in the data acquisition 
system for sending oilfield data in real-time to the central 

30 data hub. 

72. The method of claim 70 further comprising a third 
real-time transfer application server in the remote delivery 
site computer for receiving oilfield data in real-time from the 
central data hub. 

35 73 . The method of claim 70 wherein the real-time transfer 
application server establishes a real-time data transfer chain 
from the data acquisition system to a real-time transfer- 
enabled remote delivery site. 

74. The method of claim 73 wherein the real-time 
40 transfer-enabled remote delivery site comprises a real-time 

transfer utility located within a remote delivery site com- 
puter 

75. The method of claim 60 further comprising a data 
manager within the central data hub that locates data and 

45 enters new data into a database in communication with the 
central data hub. 

76. The method of claim 60 further comprising an archive 
manager for managing file data uploaded to the central data 
hub and file data generated at the central data hub via file 

5Q conversion applications. 

77. The method of claim 60 wherein the monitoring of the 
task status comprises: 

a. processing status queue task dependencies, task mes- 
sages and task statistics: 
55 b. maintaining task and order state statistics; 

c. identifying task waiting for events; and 

d. placing tasks in a dispatch queue when task dependen- 
cies are complete. 

78. The method of claim 60 wherein task dependencies 
60 comprise executing the task after other tasks have reached 

their target state. 

79. The method of claim 60 wherein task dependencies 
comprise executing the task after a period of time has 
elapsed. 

65 80. The method of claim 60 further comprising specifying 
the workflow order by a user at a user computer and sending 
the workflow order to the central data hub for processing. 
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81. A software program embodied on a computer- readable 
medium incorporating the method as recited in claim 60. 

82. A computer-implemented method for near real-time 
data delivery of oilfield data from at least one data acqui- 
sition site to multiple remote delivery sites, comprising: 

a. processing a workflow order at a central data hub 
computer that controls delivery of oilfield data from the 
at least one data acquisition site to the remote delivery 
site; 

b. transmitting oilfield data over a first communications 
network from a data acquisition site computer to the 
central data hub computer in near real-time in response 
to the workflow order; and 

c. sending oilfield data from the central data hub to a 
remote delivery site using a data server that is part of 
the central data hub, the data server communicating 
with multiple remote delivery site computers for the 
simultaneous display of the oilfield data in near real 
time at multiple delivery site computers in response to 
the workflow order. 

83. A computer implemented method for near real-time 
data delivery of oilfield data from at least one data acqui- 
sition site to multiple remote delivery sites, comprising: 
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a. electronically transferring oilfield data obtained at a 
data acquisition site from a computer at the data 
acquisition site, based on a user-specified workflow 
order program, to a central data hub computer over a 

5 communications network using a near real-time trans- 
mission protocol; 

b. receiving the oilfield data at the central data hub 
computer, formatting the data for delivery to the mul- 

]Q tiple remote delivery sites based on the delivery site 
requirements and the user-specified workflow program; 

c. routing the data to a hardcopy delivery site for hardcopy 
creation based upon the workflow as requested by the 
workflow; and 

]5 d. routing the data to the multiple remote delivery sites 
based on the user-specified workflow over a second 
communications network using a near real-time trans- 
mission protocol upon request by at least one of the 
multiple delivery sites. 
84. Asoftware program embodied on a computer-readable 
medium incorporating the method as recited in claim 83. 

***** 
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